<!DOCTYPE html>
<html>
<!-- Created by GNU Texinfo 7.1.1, https://www.gnu.org/software/texinfo/ -->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<!-- Copyright © 1988-2023 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "Funding Free Software", the Front-Cover
Texts being (a) (see below), and with the Back-Cover Texts being (b)
(see below).  A copy of the license is included in the section entitled
"GNU Free Documentation License".

(a) The FSF's Front-Cover Text is:

A GNU Manual

(b) The FSF's Back-Cover Text is:

You have freedom to copy and modify this GNU Manual, like GNU
     software.  Copies published by the Free Software Foundation raise
     funds for GNU development. -->
<title>Test Idioms (GNU Compiler Collection (GCC) Internals)</title>

<meta name="description" content="Test Idioms (GNU Compiler Collection (GCC) Internals)">
<meta name="keywords" content="Test Idioms (GNU Compiler Collection (GCC) Internals)">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<meta name="viewport" content="width=device-width,initial-scale=1">

<link href="index.html" rel="start" title="Top">
<link href="Option-Index.html" rel="index" title="Option Index">
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
<link href="Testsuites.html" rel="up" title="Testsuites">
<link href="Test-Directives.html" rel="next" title="Test Directives">
<style type="text/css">
<!--
a.copiable-link {visibility: hidden; text-decoration: none; line-height: 0em}
div.example {margin-left: 3.2em}
span:hover a.copiable-link {visibility: visible}
-->
</style>


</head>

<body lang="en">
<div class="section-level-extent" id="Test-Idioms">
<div class="nav-panel">
<p>
Next: <a href="Test-Directives.html" accesskey="n" rel="next">Directives used within DejaGnu tests</a>, Up: <a href="Testsuites.html" accesskey="u" rel="up">Testsuites</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html" title="Index" rel="index">Index</a>]</p>
</div>
<hr>
<h3 class="section" id="Idioms-Used-in-Testsuite-Code"><span>7.1 Idioms Used in Testsuite Code<a class="copiable-link" href="#Idioms-Used-in-Testsuite-Code"> &para;</a></span></h3>

<p>In general, C testcases have a trailing <samp class="file">-<var class="var">n</var>.c</samp>, starting
with <samp class="file">-1.c</samp>, in case other testcases with similar names are added
later.  If the test is a test of some well-defined feature, it should
have a name referring to that feature such as
<samp class="file"><var class="var">feature</var>-1.c</samp>.  If it does not test a well-defined feature
but just happens to exercise a bug somewhere in the compiler, and a
bug report has been filed for this bug in the GCC bug database,
<samp class="file">pr<var class="var">bug-number</var>-1.c</samp> is the appropriate form of name.
Otherwise (for miscellaneous bugs not filed in the GCC bug database),
and previously more generally, test cases are named after the date on
which they were added.  This allows people to tell at a glance whether
a test failure is because of a recently found bug that has not yet
been fixed, or whether it may be a regression, but does not give any
other information about the bug or where discussion of it may be
found.  Some other language testsuites follow similar conventions.
</p>
<p>In the <samp class="file">gcc.dg</samp> testsuite, it is often necessary to test that an
error is indeed a hard error and not just a warning&mdash;for example,
where it is a constraint violation in the C standard, which must
become an error with <samp class="option">-pedantic-errors</samp>.  The following idiom,
where the first line shown is line <var class="var">line</var> of the file and the line
that generates the error, is used for this:
</p>
<div class="example smallexample">
<pre class="example-preformatted">/* { dg-bogus &quot;warning&quot; &quot;warning in place of error&quot; } */
/* { dg-error &quot;<var class="var">regexp</var>&quot; &quot;<var class="var">message</var>&quot; { target *-*-* } <var class="var">line</var> } */
</pre></div>

<p>It may be necessary to check that an expression is an integer constant
expression and has a certain value.  To check that <code class="code"><var class="var">E</var></code> has
value <code class="code"><var class="var">V</var></code>, an idiom similar to the following is used:
</p>
<div class="example smallexample">
<pre class="example-preformatted">char x[((E) == (V) ? 1 : -1)];
</pre></div>

<p>In <samp class="file">gcc.dg</samp> tests, <code class="code">__typeof__</code> is sometimes used to make
assertions about the types of expressions.  See, for example,
<samp class="file">gcc.dg/c99-condexpr-1.c</samp>.  The more subtle uses depend on the
exact rules for the types of conditional expressions in the C
standard; see, for example, <samp class="file">gcc.dg/c99-intconst-1.c</samp>.
</p>
<p>It is useful to be able to test that optimizations are being made
properly.  This cannot be done in all cases, but it can be done where
the optimization will lead to code being optimized away (for example,
where flow analysis or alias analysis should show that certain code
cannot be called) or to functions not being called because they have
been expanded as built-in functions.  Such tests go in
<samp class="file">gcc.c-torture/execute</samp>.  Where code should be optimized away, a
call to a nonexistent function such as <code class="code">link_failure ()</code> may be
inserted; a definition
</p>
<div class="example smallexample">
<pre class="example-preformatted">#ifndef __OPTIMIZE__
void
link_failure (void)
{
  abort ();
}
#endif
</pre></div>

<p>will also be needed so that linking still succeeds when the test is
run without optimization.  When all calls to a built-in function
should have been optimized and no calls to the non-built-in version of
the function should remain, that function may be defined as
<code class="code">static</code> to call <code class="code">abort ()</code> (although redeclaring a function
as static may not work on all targets).
</p>
<p>All testcases must be portable.  Target-specific testcases must have
appropriate code to avoid causing failures on unsupported systems;
unfortunately, the mechanisms for this differ by directory.
</p>
<p>FIXME: discuss non-C testsuites here.
</p>
</div>
<hr>
<div class="nav-panel">
<p>
Next: <a href="Test-Directives.html">Directives used within DejaGnu tests</a>, Up: <a href="Testsuites.html">Testsuites</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html" title="Index" rel="index">Index</a>]</p>
</div>



</body>
</html>
